A customer device (“User Equipment” in English) is said to “belong” to the network of a given operator, called “operator network” below, when the user of this customer device has an account with this operator, whatever the access network used by the customer device to connect to the operator network. For example, these customer devices may be a fixed or mobile terminal, or a gateway at home (“Residential Gateway” in English) or situated in a company, or else a network operator gateway (“Voice Gateway” in English) such as a (DSLAM-SIP (DSLAM are the initials for “Digital Subscriber Line Access Multiplexer” in English; this is a device collecting the DSL data traffic that travels over a certain number of telephone lines).
The SIP protocol has been defined by the IETF in RFC document 3261. This protocol allows the setup, modification and termination of multimedia sessions in a network using the IP protocol. The SIP protocol has then been extended by the IETF in several other RFC documents, adding new functionalities to the SIP protocol.
The SIP protocol is used particularly in infrastructures of IMS (initials for “IP Multimedia Subsystem” in English) type. The IMS is defined by the standardization body 3GPP (“3rd Generation Partnership Project”). It is a network architecture introduced initially for mobile networks and then extended to other access means, including fixed access means using xDSL technology. This architecture allows dynamic setup, and control, of multimedia sessions between two customers and the reservation of resources at the level of the transport network for the multimedia streams. Owing to this architecture, network operators are conveniently able to implement a management policy, provide a predetermined Quality of Service and calculate the amounts to be invoiced to the customers. The IMS currently allows access to services of telephony, videophony and Presence and Instant Messaging type, of which it also manages the interaction.
When a user wishes to make use of the services provided by an IMS network, he sends the network signaling messages that may include notably various types of requests.
First of all, the customer device of the user must, allowing for exceptions (in the event of some emergency calls), register on the network. When the network is incapable of associating this registration with a preceding registration (for example following a network breakdown, or following stoppage of the customer device for a period longer than a predetermined value), the registration is considered to be an initial registration. After an initial registration, the customer device of the user must periodically send the network a request to confirm that it wishes to maintain its registration.
So as therefore to be able to register customer devices, IMS networks comprise one or more servers, generally called “S-CSCF” (initials for “Serving-Call Session Control Function” in English), which are capable (among other functions) of managing the registration procedure of the devices connected to the network.
Moreover, these networks comprise one or more servers, generally called “I-CSCF” (initials for “Interrogating-Call Session Control Function” in English)—which are furthermore often physically combined with the servers of S-CSCF type in order to constitute servers denoted by “I/S-CSCF”—which, at the moment of registration of a customer device, interrogate a server called “HSS” (initials for “Home Subscriber Service” in English) in order to be able to select an S-CSCF server having the features that are obligatorily (and, where appropriate, optionally) required in order to attain the level of service that the user subscribes to. HSS servers each contain a customer database, and are therefore equivalent in IMS networks to the “HLR” (initials for “Home Location Register” in English) servers used in GSM networks. Each HSS server contains the “profile” of a certain number of customer devices in the network, this profile comprising their registration state, authentication and location data and subscribed-to services.
Finally, at the periphery of the IMS network, there may be one or more IBCF (initials for “Interconnection Border Controller Function” in English) server(s): these are SIP servers situated on the border of the IMS network and implementing the specific processing operations that are necessary, where appropriate, in order to make an interconnection with another SIP network. This IBCF function is often performed by a piece of equipment of SBC (initials for “Session Border Controller” in English) or I-SBC type.
Within the framework of a network and of services using the session control protocol SIP, the choice of services to which a user can have access at a given instant is dependent on various factors.
Thus, this choice is dependent on the provision of services to which the user has subscribed. It is also dependent on the customer device used by the user and on the technical features thereof: this is because the customer device may give the misleading impression that it is able to call upon services to which the user is not in fact entitled, or conversely may not allow the user to use certain services to which he has nevertheless duly subscribed.
This choice is likewise dependent on the various intermediate networks used for associating the customer device and the operator network. For example, in a mobility situation, the access connectivity may be provided by a first network, for example a network local to the country visited by the user. Equally, this first network may not be directly connected to the operator network, so that the use of at least one supplementary transit network is necessary. In point of fact, each of these networks may have technical features of their own, and these networks may not all have the means to provide the services to which the user could have access if he were directly connected to his operator network. Even though these networks could individually have such means, it may be that the operators that manage them have not entered into the prior interconnection agreements that are necessary for end-to-end implementation of some of the technical features that are required for the user to be able to make full use of his offer of services.
There is a double stake in that the customer device of the user and the operator network are able to determine what services are effectively accessible to the user:                for the customer device, it is a matter of avoiding returning an erroneous piece of information to the user so as to prevent the latter from attempting to call upon services that will not be able to be honored, which would cause both unnecessary traffic in the network and a risk of incomprehension and dissatisfaction for the user;        for the operator network, it is a matter of avoiding addressing requests destined for failure to the customer device, which would cause unnecessary resource consumption.        
This problem is illustrated in FIG. 1. In this figure, a user (denoted by “U” in the figure) has subscribed to the services S1, S2, S3, S4 and S5 with his service operator. The customer device (denoted by “T” in the figure) that he uses to connect to the network has the means for providing the services S2, S3, S4, S5 and S6. The user is on the move in a foreign country, and he uses the network of an operator that is local to the country that he is visiting (network denoted by “RI1” in the figure) as an intermediate network for connecting to the operator network (denoted by “RO” in the figure). RI1 has the means for providing the services S1, S3, S4, S5 and S6. In point of fact, RI1 does not have any direct connection to the operator network RO, and uses a transit network (denoted by “RI2” in the figure) to join the operator network RO. This intermediate network RI2 has the means for providing all the services S1, S2, S3, S4, S5 and S6, but the interconnection agreement between the intermediary RI2 and the operator network RO does not anticipate compatibility with the service S3. In the end, only S4 and S5 are accessible to the user U, but, on the basis of the compatibility indications provided by T, said user will think that the services S2, S3, S4, S5 and S6 are accessible to him, and risks a vain attempt to use the services S2, S3 and S6. Equally, the operator network RO will think that the services S2, S3, S4 and S5 are accessible, whereas sending requests relating to the services S2 and S3 to T will result in failure.
There are various methods in the prior art that allow a customer device to acquire information about the services that are accessible to it.
Thus, according to the standard TS 183 063 from the ETSI (European Telecommunications Standards Institute) (cf. notably section 5.3.1.1 and annex A.4.1), a user registered with an IMS network may present this network with a request for provision of services (“service packages and broadcast services”) related to the reception of television channels via Internet (IPTV); the network authorizes the required services so far as they are compatible with the subscription of the user with the operator of the network, and the user is informed of what the network has authorized.
However, when an operator network agrees to provide such a service, it does not take account of any technical limitations that this operator network might itself bring, or, where appropriate, of the intermediate networks between it and the customer device of the user, so that, in unfavorable scenarios, the service will not be provided for the user after all despite the authorization given by the operator network.
Conversely, in the specific case of mobile access means standardized by the 3GPP (“3rd Generation Partnership Project”), provision is made (according to 3GPP standard TS 23.401) for, during the radio attachment, the visited network (that is to say the network used at a given instant by the customer device for providing its connectivity) to spontaneously indicate to the customer device that it is capable of providing the SIP/IMS voice service (“IMS voice over PS sessions” parameter) and the SIP/IMS emergency services (“Emergency Service Support” parameter). However, these provisions are limited to the services that have just been mentioned, whereas the user of the customer device might wish to know whether or not certain other services in which he has particular interest are accessible to him.
Still in the case of mobile access means, the operator of the user may likewise, according to 3GPP standard TS 24.167, configure the services that it provides and/or authorizes in the customer device. However, this is by definition a static provision: an update of this information on a registration session by registration session basis would be excessively onerous to implement; moreover, it presupposes the deployment of a configuration infrastructure, which is not guaranteed. Above all, this list of services does not take account of the possible limitations that might be entailed by the existence of intermediate networks.
It appears, in conclusion, that these known techniques, even combined with one another, are not capable of solving the problem overall. Notably, they do not make it possible to take account of the restrictions entailed by the use of an intermediate network that would be technically incapable of providing certain services, or that would not authorize certain services, and therefore do not allow an operator network to know what services it can effectively provide for a customer device belonging to this operator network, among the services desired by the user of this customer device.